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INTRODUCTION 


Reliable  software  for  complex  computer  systems  within  the  military  and  commercial 
systems  continue  to  be  an  area  for  investigation  and  improvement  (refs  1 ,  through  7). 
High  costs  for  embedded  computers  and  poor  performance,  as  compared  to  ambiguous 
software  requirements,  offer  an  opportunity  for  application  of  software  tools  to  enhance 
software  reliability,  quality,  and  maintenance. 

Research  and  development  work  has  been  completed  by  McCabe  in  a  complexity 
measure  for  the  control  structure  of  a  computer  program  by  adapting  graph  theory  (refs 
4  and  7).  The  cyclomatic  complexity  of  the  graph  is  related  to  the  number  of  independ¬ 
ent  loops  in  the  graph.  McCabe  relates  the  cyclomatic  complexity  to  the  minimum 
number  of  test  paths  which  are  needed  to  pass  through  all  the  branches  in  the  graph  of 
the  program. 

The  process,  when  implemented,  can  generate  the  minimum  set  of  tests  for  exer¬ 
cising  the  program  and  assuring  software  reliability  (refs  4,  5,  and  7). 

More  specifically,  the  design  is  impacted  by  forcing  a  structured  approach  to  the 
logic,  thereby  limiting  complexity  and  yielding  more  robust,  reliable  software  by  building 
in  quality.  In  addition,  this  process  can  generate  the  minimum  set  of  tests  necessary  to 
effectively  test  every  path  through  the  program’s  logic,  improving  reliability  by  achieving 
greater  test  coverage. 

Based  on  the  above  research,  the  155  mm  self-propelled  Howitzer  Improvement 
Program  (HIP)  generated  a  software  complexity  requirement  for  the  project.  The  Joint 
U.S.  Army-lsraeli  Defense  Force  HIP  contract  stated  that  the  software  cvclomatic 
complexity,  as  defined  in  the  National  Bureau  of  Standards  Special  Publication  500-99, 
shall  not  exceed  9  (ref  7).  In  addition,  the  U.S.  Army  Armament,  Munitions  and  Chemi¬ 
cal  Command,  Product  Assurance  Directorate  at  Picatinny  Arsenal,  developed  an 
automated  Complexity  Analysis  Tool  (CAT)  to  be  used  in  the  HIP  project  (ref  3).  The 
CAT  is  a  quality  assurance  tool  which  provides  a  quantitative  measure  of  software 
quality,  structure,  robustness,  testability,  and  maintainability. 

BACKGROUND 

The  155  mm  self-propelled  HIP  concept  is  the  result  of  efforts  of  government  and 
private  contractors  to  define  a  multiphased,  major  cannon  field  artillery  weapon  system 
in  response  to  the  Heavy  Brigade/Division  Field  Artillery  Fire  Support  Weapon  System 
Mission  Element  Need  Statement  (MENS)  dated  12  December  1980  (ref  8).  The  HIP 
concepts  specifically  address  four  areas  of  system  deficiencies:  responsiveness, 
survivability,  terminal  effects,  and  RAM  (reliability,  availability,  and  maintainability). 
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The  HIP  consists  of  two  configurations  where  one  is  the  U.S.  Ml  09  howitzer  and 
the  other  is  the  Israeli  Ml  09.  The  U.S.  configuration,  which  is  in  limited  production,  is 
the  M109A6  while  the  Israeli  system  is  the  M109A1C. 

The  HIP  software  products  are  being  developed  by  several  contractors  both  in  the 
U.S.  and  in  Israel.  The  major  software  products  are: 

1 .  Automatic  Fire  Control  System  (AFCS) 

2.  Prognostic  and  Diagnostic  Interface  Unit  (PDIU) 

3.  Simplified  Test  Equipment  Expandable  (STE-X) 

4.  Israeli  Automatic  Fire  Contra1  System  (AFCS/IS) 

5.  Institutional  Fire  Control  System  Trainer  (IFCST) 

6.  Institutional  Maintenance  Trainer  (IMT) 

The  HIP  self-propelled  howitzer  is  equipped  with  an  AFCS  which  includes  and  is 
supported  by  computer  resources.  The  AFCS  eliminates  the  need  for  section  personnel 
to  exit  the  vehicle  during  emplacement  and  displacement  of  the  weapon  due  to  a  com¬ 
plete  on-board  gun-laying/reference  system. 

The  need  for  conventional  survey  support  is  eliminated  through  the  incorporation  of 
a  computer  support  Modular  Azimuth  Position  System  (MAPS)  which  includes  a  Dy¬ 
namic  Reference  Unit  (DRU).  The  M109A1C  configuration  uses  the  Gun  Orientation 
Navigation  System  (GONS)  developed  in  Israel  as  the  DRU  alternative. 

The  Display  and  Control  Unit  (DCU)  is  the  man-machine  interface  for  the  control  of 
the  AFCS.  This  DCU  enables  the  Chief  of  Section  (CS)  to  make  inputs  and/or  override 
the  AFCS. 

Ballistic  computations  (technical  fire  direction)  are  accomplished  on-board,  using 
inputs  from  the  Battery  Computer  System  (BCS)  to  the  AFCS.  The  AFCS  computer 
controls  and  displays  firing  data  on  the  DCU.  The  AFCS  controls  the  electrical/ 
mechanical  servo  system  to  drive  the  cannon  to  the  computer  azimuth  and  elevation. 

The  M109A6  employs  two  Single  Channel  Ground  and  Airborne  Radio  Systems 
(SINCGARS),  frequency  hopping,  VHF  radios  to  execute  digital  and  voice  communica¬ 
tions.  The  digital  communication  is  controlled  by  the  AFCS  and  is  a  second,  vital  link  in 
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the  process  of  enhancing  survivability  and  responsiveness.  The  M109A6  can  communi¬ 
cate  directly  with  its  Fire  Direction  Center  (FDC)  computer  or  with  a  variety  of  target 
acquisition  systems,  either  directly  or  by  relay  through  the  FDC,  to  process  the  mes¬ 
sages  required  to  perform  its  functions.  The  highly  automated  communications  proc¬ 
essing  requires  no  direct  intervention  by  the  howitzer  crewman.  The  main  functional 
areas  addressed  by  the  digital  communications  system  are  fire  missions,  logistics,  and 
movement. 

The  PDIU  and  STE-X  components  are  used  primarily  as  built-in-test  (BIT),  Built-in- 
Test-Equipment  (BITE),  and  maintenance  support  programs  to  diagnose  faults  and 
failures. 

In  addition  to  an  Embedded  Trainer  Controller  (ETC)  on  board  the  howitzer  and 
within  the  AFCS,  the  IFCST  and  IMT  are  used  for  troop  operational  training  and  mainte¬ 
nance  training. 

Detailed  descriptions  of  the  AFCS  and  general  information  regarding  the  HIP 
management,  acquisition  strategy,  development,  coordinated  tests,  and  plans  for 
support  are  contained  in  the  Computer  Resources  Management  Plan  (CRMP)  for  HIP 
(ref  8). 


DISCUSSION 

All  software  for  HIP  was  developed  in  a  structured  manner  and  documented  in 
accordance  with  the  government  requirements  to  insure  integrity,  quality,  and  main¬ 
tainability  (ref  1).  The  U.S.  Department  of  Defense  standard  Ada  programming  lan¬ 
guage  was  used  in  over  90%  of  the  code  for  the  AFCS.  Quality  requirements  were 
applied  and  enforced  to  keep  the  complexity  and  size  of  individual  modules  to  a  mini¬ 
mum.  The  software  was  tested  at  various  levels.  Key  contributing  elements  in  this 
successful  program  were  early  up-front  user  requirement  definitions,  Ada,  the  use  of 
software  metrics  like  McCabes  Cyclomatic  Complexity,  cooperation  among  contractors 
and  government  personnel,  and  a  strict  Independent  Verification  and  Validation  (IV&V) 
program  implemented  by  the  government.  One  key  was  an  intensive  field  stress  test 
which  shook  out  major  system  errors  not  detected  by  normal  testing. 

IV&V  is  a  process  and  a  major  activity  of  the  total  quality  program  (both  software 
and  hardware)  to  independently  assess/confirm  compliance  with  requirements. 
(Specific  IV&V  tasks  and  details  for  HIP  are  described  in  ref  8.) 

Within  the  design/code  verification  process  of  the  IV&V  program  for  HIP,  the 
software  complexity  for  all  delivered  software  was  assessed.  The  automated  CAT  was 
used,  as  well  as  manual  graphical  techniques,  to  monitor  contractor  performance  in 
meeting  the  cyclomatic  complexity  requirement  of  not  exceeding  nine  (9). 
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However,  due  to  multiple  contracts  for  HIP  to  address  funding  and  program  issues, 
the  software  complexity  requirement  was  described  to  meet  specific  areas  of  code. 

r  or  example,  for  new  code,  the  software  cyclomatic  complexity  in  accordance  with 
NBS  500-99  (ref  7)  shall  not  exceed  a  complexity  of  seven  (7)  for  the  Program  Design 
Language  (PDL)  and  nine  (9)  for  source  code,  derived  from  implementation  of  the  PDL. 
The  complexity  limit  of  twelve  (12)  shall  not  be  exceeded  for  software  units  which  have 
redesigned  as  a  result  of  software  trouble  report  corrective  action.  Software 
t  riple  reports  are  normally  written  if  a  software  engineer  discovers  a  problem  within 
u.e  software  life  cycle  process  and  during  software  testing. 

For  modified  code  for  previously  developed  units  exceeding  a  complexity  limit  of  ten 
(10),  modifications  to  each  of  these  units  shall  be  implemented  so  as  to  achieve  a 
complexity  growth  not  exceeding  1 5%.  For  previously  developed  units  with  a  complex¬ 
ity  limit  of  ten  (10)  or  less,  modification  to  each  of  these  units  shall  be  implemented  so 
as  to  achieve  a  complexity  limit  of  not  more  than  twelve  (12). 

Additionally,  in  the  computation  of  software  complexity,  the  Case  Statement  shall 
have  complexity  equal  to  an  IF  statement  (e.g.,  complexity  =  1). 

MULTIPLE  CONTRACTS 

During  initial  phases  of  the  HIP,  a  contract  definition  period  clarified  the  software 
requirements  for  the  AFCS.  This  period  involved  many  meetings  with  the  prime  con¬ 
tractor,  subcontractors,  and  both  the  U.S.  and  Israeli  government  representatives. 

The  HIP  project  progressed  into  Full  Scale  Engineering  Development  (FSED) 
where  extensive  software  documentation  reviews  were  held,  audits  were  performed, 
and  multiple  meetings  were  conducted  to  ensure  that  the  prototype  software  performed 
in  accordance  with  the  requirements.  During  this  development  phase,  extensive  testing 
was  performed  at  the  Computer  Program  Configuration  Item  (CPCI)  level  and  Unit  level 
as  well  as  System  Integration  level.  Bench  level  testing  integrated  each  CPCI  into  the 
*CCS  Later  in  the  testing  process,  field  level  testing  was  performed.  As  a  result,  the 
AFCS,  PDIU,  and  DRU,  as  well  as  other  components,  were  integrated  into  a  fully 
functional  howitzer. 

The  cyclomatic  complexity  requirement  enabled  testing  to  become  easier  and  mc^e 
manageable  since  a  minimum  amount  of  test  paths  were  required  >n  order  to  qualify 
each  CPCI  In  addition,  the  CAT  produced  graphical  representatives  of  the  testing 
paths  chat  any  retesting  or  regression  testing  for  each  CPCt  could  be  accomplished 
in  a  i'lT.eiy  and  accurate  manner. 
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Since  the  FSED  contract  placed  a  lot  of  emphasis  on  government  reviews,  software 
documentation,  testing,  and  strict  controls  on  the  cyclomatic  complexity  limits,  future 
work  will  be  minimized  to  make  software  enhancements  and  retest  each  CPCI.  Thus, 
the  future  versions  of  production  software  for  each  CPCI  will  become  easier  to  maintain, 
upgrade,  and  test  as  requirements  from  users  change  to  meet  military  needs.  Life  cycle 
software  maintenance,  supportability,  field  reprogramming,  and  efforts  required  to 
complete  IV&V's  will  become  simplified  due  to  the  up  front  efforts  performed  during 
FSED. 


CONCLUSIONS 

Software  costs  for  military  projects  are  rising  each  year  and  methods  in  defining 
software  lequirer.ients  are  important  to  reduce  ambiguity.  In  addition  to  clear,  concise 
requirement  definition  of  software  products,  it  is  also  extremely  important  to  reduce 
supportability  and  maintenance  costs  Enhancements  and  upgrades  to  software  can 
sky  rocket  if  good  controls,  measures,  and  software  tools  are  not  available  during  the 
early  phases  of  start-up  projects. 

The  HIP  project  combined  some  of  these  ideas  and  concepts  in  a  successful 
software  design  from  development  to  limited  production.  The  research  performed  on 
the  application  of  software  test  tools  (refs  7  and  9)  and  the  development  of  CAT  (ref  3) 
which  was  used  on  HIP  provided  a  qualitative  and  quantitative  measure  of  software 
quality.  The  cyclomatic  complexity  metric  and  CAT  improved  the  structure,  robustness, 
testability,  and  maintainability  of  the  software. 

The  complexity  metric  will  be  a  useful  tool  for  software  upgrades  to  meet  military 
user’s  needs  since  regression  testing,  redesign  work,  and  maintenance  will  become 
easier  with  the  graphical  aids  and  reduced  testing  paths.  This  metric  in  combination 
with  Ada,  IV&V,  and  government/contractor  reviews  should  be  useful  in  reducing 
software  costs  and  maintenance. 

Follow-on  study  should  be  performed  to  quantify  these  benefits  in  terms  of  time, 
schedule,  labor,  and  cost.  A  longitudinal  study  which  also  looks  at  correlations  between 
cost  savings  versus  error  rate,  reliability.  ar-d  modifiability  would  be  a  very  useful  re¬ 
search  project  for  military  applications  and  commercial  use. 
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